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DRM's security model 
o The DRM master has all the rights; 
e A DRM client can ask the DRM master to authenticate him; 


ə Once authenticated, a client can basically do everything it 
wants. 


Who can be the DRM master? 
o Needs to have the CAP_SYS_ADMIN (root); 


o One master at the time; 


o The first one to request it gets it; 


o The DRM master rights can be released. 
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Current DRM authentication scheme 


Who actually needs to be the master? 
o XServer(s); 
o Anything else? 


The X Server and DRM_MASTER 


ə Limit modesetting calls to the currently active X-Server; 


ə Isolate applications between X-Servers? 
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X-Servers and VT-switches 
e X-servers are located on different VT; 
oe Switching user sessions is done by doing a VT-switch; 


o Before VT-switching, the X-Server must release the 
DRM_MASTER rights; 


o When entering the VT, the new X-Server must acquire the 
DRM_MASTER rights; 


e If it fails, the new X-Server cannot authenticate new clients. 


Buffer-sharing with GEM 
@ Clients need to be authenticated/associated with a MASTER; 
ə A GEM buffer is shared by calling the GEM flink IOCTL; 


e This buffer is then shared between all the “minors” 
authenticated by the MASTER (rw). 
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DRM's authentication problems 
o 


VT-switching problems 


o There is a potential synchronisation problem when switching; 


o A malicious root application may try to acquire the 
DRM_MASTER rights in a loop and steal them from a 
legitimate X-Server when a VT-switch occur. 


Confidentiality /Integrity problems 


Applications within a X-Server can access others’ shared buffers 
(GEM flink). 


Non-graphical applications (GPGPU, video encoders) 


Non-graphical applications cannot ask the X-Server to authenticate 
them in order to access the GPU. 
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Fixing Buffer Sharing 


Fixing GEM buffer sharing 

ə Split MASTER into MASTER and GEM_MASTER; 
ə Allow multiple GEM_MASTERs; 

Only root users can became GEM_MASTERs; 


Allow sharing only from minors to masters; 


It doesn't break the userspace! 
— mitigates GEM sharing’s security problem; 


— encourages the use of DMA-Buf for new applications! 


Allow non-authenticated GPU clients 
ə Non-GEM-flink users may not pose security problems; 


e They should be able to access the GPU without a MASTER 
(x-server); 


o Let the driver/hw actually isolate GPU users; 
ə Isolation can be done using GPU VMs/pushbuf validation; 
ə > allow GPGPU/video encoding without a MASTER. 


Problems 


o Some drivers/devices may not be able to isolate GPU users; 
ə What should be done? 
ə Export a DRM attribute (provides_client_isolation)? 


o let udev change the permissions to only allow root users? 


Is VT really needed nowadays? 
e KMSCon can become a system compositor; 
o lt can be responsible for forwarding events to the right 
compositor; 
e lt can allow compositors to change the modesetting (only the 
current one); 
e lt can provide terminals and deprecate VTs. 


What should be done with the MASTER mode? 
ə If using KMSCon as a system compositor; 
e KMSCon would acquire and never release the MASTER 
attribute; 

o We can leave MASTER as is! 
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Further secure DMA-Buf 


DMA-Buf 
ə Allows sharing buffers with only the needed clients; 
o But we cannot specify the sharing rights; 
o We could use LSM to allow (pwrite/pread/mmap/unmmap); 
o We can use SELinux to do access control on DMA-Buf; 


e That will complete buffer sharing security. 


Thank you for listening! 
Questions or other propositions? 


